Related to previous work at #273.

This is missing documentation and also some justification why this change is relevant and how applications are going to use these changes.

Changing username/password buffer size to 64K looks like a wrong approach to me. Can't this be done better using webauth and opening a url?

What vendors? And how is this used? If you cannot even explain how this is used or why these changes are useful for anyone, I have a hard time seeing any value in this patch.

@schwabe For example AWS VPN Client, when making the authentication with SAML it sends N/A as username and the password with the SAML response that is a long string. Currently to connect to the VPN Server in AWS for the company I work I need to apply that patch and compile it to establish the connection. The benefits from this basically is bringing support for these kind of scenarios (provide the SAML response into the password argument), I don't know other vendors but from my experience this is the current solution I have to make it work. Also AWS VPN Client supports Ubuntu, MacOS and Windows but other Linux distros are out of support.

In this blog you will have more context of what we are talking about: https://smallhacks.wordpress.com/2020/07/08/aws-client-vpn-internals/

@schwabe do you have a better way to support more length in the password argument? Unfortunately I don't have any experience with C/C++ and if you say this is not the right way to implement it I believe you. However I ask you please if you can provide us a way to solve this scenario since you have more insight in OpenVPN.

So it is basically a hacky method supported only by AWS. I am not really sure I want to bring that hack into the main OpenVPN code base.

Yes we can call it like that 😅 I'm thinking if we can support longer passwords lengths via arguments. What do you think? The default behavior will remain for OpenVPN but for this case we can do e.g:

openvpn --password-length="bytes"

So will work for AWS and perhaps other vendors that follow this scenario.

@schwabe it's been sometime we talked about this, do you think the arguments approach would be possible?

The question is still why should support this hacky way that is not even documented that is properitary to OpenVPN when we have a well documented way to do this properly.

Is it documented already? For passing a long password? Could you show me please? @schwabe

@sant123 there is no reason to pass such a super long password apart from the hacky AWS client. We have better methods than that to support different autehtnication methods like SAML.

Yes I understand that, but that’s how AWS implemented it’s system authentication. If there would be other way believe me I’ll take it but this is how is implemented now. They ask for a long password and that’s now how is currently working for @m4dc4p, other people and myself. Don’t know other vendors but wanted to have another way to configure these kind of scenarios @schwabe

Yeah, but I don't think the Lemming approach here the way to go. Just because someone else jumped of a cliff, does not mean we have to follow and jump off the same cliff too. AWS did something to the OpenVPN protocol, which we do not want to support since there are multiple bad things about their approach that break compatiblity with non-AWS servers and while AWS does not care, we care about compatiblity. And I won't break compatibility with the current clients just to have AWS hack in OpenVPN.

That's fair enough. Thanks for having the patience to explaining us this 👍🏼

In context of https://github.com/jkroepke/openvpn-auth-oauth2/ I'm also interest into this. Mainly increase auth-token, because I would like to pass the ID Token from OIDC Provider to VPN clients to allow a full stateless SSO experience. ID Tokens can be large (up to 8K).